…ze (#4302)

Round 3 of the 8.x cold-start trim begun in #4295/#4296. Two more lazy
caches in EventGraph that paid an O(n) linear walk on first lookup of
each name; pre-populate them at Initialize from already-known data so
the first request of every alias is a hit.

* _byEventName is keyed by EventTypeName and OnMissing was a
  AllEvents().FirstOrDefault(x => x.EventTypeName == name) walk per miss.
  Add Fill() for every registered mapping in the same loop that already
  walks _events. First lookup of each alias is now O(1).

* _aggregateTypeByName is keyed by aggregate alias and findAggregateType
  iterated Options.Projections.AllAggregateTypes() on miss. Walk that
  collection once at Initialize and Fill the entries up front. Same shape
  as the existing OnMissing logic, just moved off the request path.

Behavior unchanged: in both caches, the existing OnMissing/Fill paths
remain intact for any name that wasn't registered at Initialize time
(rare but possible -- e.g. types added via _events.OnMissing later).

Continues the 8.x cold-start trim. The remaining items are 9.0 scope and
each tracked separately under the Marten 9.0 milestone.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three independent root causes feed the test-flake pattern that's been
hitting recent PRs (#4279, #4281, #4292, #4295, #4296, #4302). All three
are localized; this PR addresses each.

## Root cause 1: shared static random sequence

Target.cs defines `private static readonly Random _random = new Random(67)`
that is consumed by ~80 tests across LinqTests + DocumentDbTests. Each
Target.Random() / GenerateRandomData() call advances the shared sequence,
so a test's effective random data depends on which sibling tests ran
before it. xUnit discovery order is mostly stable but NOT guaranteed
identical run-to-run, especially across CI workers with different load,
.NET TFM combinations, etc. A small order shift consumes a different
slice of the sequence and produces different test data — silently flipping
assertions that depend on exact counts or distributions.

Fix: introduce `Target.ResetRandomSeed(int seed = 67)` so a test that
genuinely depends on specific random data can pin the sequence at the
start. Remove the readonly modifier on _random to allow rebinding.

Updated tests to call ResetRandomSeed():
- Bug_605_unary_expressions_in_where_clause_of_compiled_query (3 facts)
- Bug_3337_select_page.try_it_out
- query_against_child_collections.buildUpTargetData (covers
  can_query_on_enum_properties and many more)

Also tightened Bug_605's assertion: it was hardcoded to `.ShouldBe(15)`
but the real point of the test is "compiled query == inline LINQ query for
the same expression"; the page size of 15 is incidental. Compare against
expected.Count instead so the test is robust to data variance.

## Root cause 2: DateTimeOffset.UtcNow inside a shared LINQ expression

`child_collection_queries.cs:67` was registering this where-clause for the
acceptance suite:

    @where(x => x.Children.Any(c => c.NullableDateOffset <= DateTimeOffset.UtcNow));

That expression runs in BOTH the in-memory LINQ-to-objects "expected"
provider AND the LINQ-to-SQL "actual" provider. Each provider evaluates
DateTimeOffset.UtcNow at its own moment. Target.NullableDateOffset values
are ±60 seconds of "now" from random data; values within microseconds of
either provider's "now" can land on opposite sides of <= and disagree.

Fix: capture a fixed `asOf = DateTimeOffset.UtcNow.AddDays(1)` in the
static ctor and use that as the boundary. The expression now embeds a
constant timestamp that both providers see identically. AddDays(1) puts
it well beyond the test data range so the predicate is meaningfully true
for matching rows.

## Root cause 3: ordering assumptions on server-generated Guids

Bug_4282 asserted `ids.ShouldHaveTheSameElementsAs(doc1.Id, doc3.Id)`
after `OrderBy(x => x.Id)`. The IDs are server-generated Guids; their
sort order does not in general match declaration order (Marten uses
sequential Guids in many configs but not always, depending on the
StoreOptions in scope and the underlying provider). Switched to
set-membership: `Count == 2` plus ShouldContain for each expected id.

## Root cause 4 (defensive): ShouldBeEqualWithDbPrecision tolerance

The helper used to round both sides to 100µs with truncation (`Ticks /
1000 * 1000`) and then ShouldBe. The math works in the common case, but
the assertion was fragile under loaded-runner clock-comparison edge
cases. Switched to a 1ms tolerance check; widely above the worst-case
PostgreSQL truncation (9 ticks ≈ 0.9µs) but still tight enough to catch
real semantic differences. Also produces a clearer failure message when
it does fire.

## Verification

Stress-ran the previously-flaky suites locally: 5x consecutive runs of
all 178 LinqTests.Bugs tests, no failures. All 123 tests across Bug_605,
Bug_4282, Bug_3337, query_against_child_collections, and
child_collection_queries pass. Bug_2283 in DocumentDbTests passes.

Closes #4310.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>